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RAAF  Command  Support  Systems 

EXECUTIVE  SUMMARY 


A.  Introduction 

DAFPOL  tasked  DSTO  to  define  the  broad  capabilities  required  of  future  RAAF 
Command  Support  Systems.  The  study,  in  which  over  100  people  were 
interviewed  throughout  the  command  chain  from  ACAUST  to  the  OCWG  and 
COSQN,  also  examined  Air  Command's  requirement  for  sector  air  defence, 
logistics,  and  personnel  information.  Although  no  time  horizon  was  placed  on 
the  Study,  the  capabilities  outlined  in  the  Report  are  likely  to  be  achieved  within 
the  next  10  to  15  years. 

This  report,  which  presents  the  results  of  a  12-month  study  by  DSTO,  addresses 
the  broad  capabilities  required  of  future  RAAF  command  support  systems.  The 
work  was  completed  as  an  introductory  report  to  a  project  definition  study  for  a 
new  Air  Command  Support  System.  The  Air  Command  Support  System  will  be 
developed  as  part  of  the  JP2030  project.  The  requirement  for  Command  Support 
Systems  is  recognised  by  the  1994  Defence  White  Paper  which  listed  Command, 
Control  and  Communications  as  a  Key  Role. 

B.  Current  Command  Support  System  Capabilities 

This  report  has  adopted  the  following  definition  of  a  Command  Support  System: 

"A  Command  Support  System  exists  to  facilitate  the  mission  of  the 
organisation." 

For  missions  to  be  completed  successfully,  four  levels  of  fusion  are  required 
within  organisations:  sensor  fusion,  data  fusion,  information  fusion  and 
knowledge  fusion.  In  the  development  of  RAAF  command  support  systems,  the 
major  effort  has  been  put  into  sensor  fusion  (NADACS)  and  data  fusion 
(AHQTS,  AHQLAN).  Rudimentary  information  fusion  has  occurred  (BACSS)  in 
isolation  from  other  systems.  To  date,  no  knowledge  fusion  has  taken  place. 

C.  Approach  to  Defining  Broad  Capabilities 

The  ADF  Command  and  Control  Information  Systems  Plan  has  developed  on 
the  understanding  that: 

"The  user  requirement  for  a  Command  Support  System  is  never  static,  and  will 
always  evolve  with  experience." 

The  statement  is  valuable  as  it  recognises  the  djmamics  of  the  issue.  However, 
the  Plan  does  not  consider  the  properties  or  qualities  of  Command  Support 
Systems  which  change  user  requirements  in  themselves.  The  main  thrust  of  this 
document  concerns  this  issue  of  changes  in  the  requirements  of  command 
support. 


A  clear  distinction  has  been  drawn  between  Command  Support  Systems  and 
Information  System  capabilities.  The  benefit  of  this  approach  is  that  capabilities 
unique  to  Command  Support  Systems  can  be  separated  from  those  unique  to 
general  Information  System  capabilities.  It  is  possible  also  that  such  an  analysis 
will  be  conducted  when  procming  future  systems.  All  of  the  general  assets  of 
Information  Systems,  such  as  hardware,  networks,  databases  and  middleware, 
will  be  procured  independently  of,  and  separately  to,  the  software  which  deals 
with  its  main  business  fimctions,  namely,  command  and  control. 

D.  Command  Support  System  Capabilities 

Three  important  concepts  underlie  the  broad  capabilities  and  operations  of  a 
Command  Support  System.  They  recognise: 

•  Individual  commanders  have  information  requirements  which  depend  on 
their  current  situations  and  individual  backgrounds.  This  means  that  the 
information  requirements  for  given  individuals  and  situations  carmot  be 
pre-specified  completely.  Commanders  can  tailor  their  requirements  as 
their  situations  change. 

•  Individual  commanders  complete  their  assigned  tasks  by  applying  their 
necessary  knowledge,  required  information,  tools  for  manipulation  of  the 
information,  and  views  of  the  information  which  supports  the  tasks  they 
are  performing.  As  such  tools,  tasks,  views  and  information  all  change 
over  time,  commanders  must  be  able  to  transform  their  varied  tools, 
tasks,  views  and  information  to  meet  new  situations  and  changing 
requirements. 

•  Individual  commanders  may  operate  in  environments  which  are 
independent  of  Information  System  implementation  issues.  This  means 
that  the  commanders'  contexts  are  those  of  their  organisations  and 
current  situations,  and  not  of  the  information  system. 

Users  of  a  Command  Support  System  require  a  wide  variety  of  tools.  There  are 
three  main  categories  of  tools:  distributed  decision-making  tools;  situation 
awareness  tools;  and  situation  assessment  tools.  Distributed  decision-making 
tools  permit  the  organisations  in  which  users  are  operating  to  be  modelled 
within  the  software  system. 

The  primary  future  quality  of  such  systems  is  their  ease  of  use.  Usability  will  be 
enhanced  by  enabling  users  to  effect  often  radical  shifts  in  the  facilities  available 
to  them.  A  Command  Support  System  does  not  provide  merely  a  pre-defined  set 
of  services.  It  acts  as  a  supportive  environment  for  the  creation  of  services 
tailored  to  meet  the  requirements  of  individuals,  groups  and  organisations  in 
given  situations. 

E.  Information  System  Capabilities 

Interoperability  of  Information  Systems  is  the  key  to  providing  the  functionality 
required  by  users  of  Command  Support  Systems.  Our  current  concept  of 
interoperation  through  simple  message-based  systems  is  insufficient  as  a 
medium  to  deliver  the  command  support  requirements  of  the  future.  Future 
Information  Systems  need  to  enhance  the  following  capabilities: 


•  Co-operation  to  permit  the  joint  completion  of  tasks. 

•  An  object-oriented,  open,  standards-based  approach  to  information 
system  development. 

•  Middleware  should  be  included  to  provide  a  high-level  platform- 
independent  environment  to  the  development,  maintenance,  and  run¬ 
time  support  for  distributed  applications. 

•  Architectures  and  standards  necessary  for  distributed  object  management 
should  be  adopted. 

Integration  of  Information  Systems  would  imply  the  global  naming  of  data 
Items  and  consistency  between  all  Information  Systems— even  though 
integration  of  all  Information  Systems  is  very  difficult,  according  to  tL 
information  technology  community.  Integration  will  occur  at  the  component 
level  where  component  is  defined  as  a  whole  Information  System.  Component- 
oriented  integration  is  useful  as  it  models  the  system  as  a  network  of  interacting 
components,  avoiding  any  standardisation  on  individual  architectures  and 
enabling  the  independent  definition  of  components  so  that  components  can  be 
used  in  different  architectural  configurations  to  meet  requirements  as  they 
evolve.  Not  only  does  the  new  Air  Command  Support  System  need  to  use  many 
existing  information  systems,  it  also  needs  to  interoperate  with  a  number  of  other 
RAAF,  ADF,  Government  and  civil  Information  Systems. 

F.  Communications 

Studies  are  underway  to  determine  how  the  Defence  Fixed  Networks  can 
migrate  to  systems  employing  standard,  open,  non-proprietary  interfaces  and 
protocols.  The  adoption  of  international  standards  for  military  communications 
will  enable  a  dynamic  distribution  of  computing  resources  and  communication 
capacities  across  command  centres.  Another  key  consideration  to  be  faced  when 
developing  a  new  Air  Command  Support  System  are  the  step-wise  increases  in 
capacity  and  performance  developed  by  such  a  migrating  system.  How  to  make 
the  best  use  of  currently-evolving  communication  infrastructures  is  a  key  issue 
for  a  future  Air  Command  Support  System. 
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1.  Introduction 


1.1.  Background 

Recent  strategic  documents  have  highlighted  the  increasing  importance  of  Command, 
Control  and  Communications.  In  1993,  the  Strategic  Review  document  listed 
Command,  Control  and  Communications  as  a  Support  Role.  In  1994,  the  Defence 
White  Paper  listed  Command,  Control  and  Communications  as  a  Key  Role.  Effective 
Command,  Control  and  Commimications  enables  increased  leverage  of  the  ADF's 
limited  resources. 

Under  Task  Air  93/025,  DAFPOL  tasked  DSTO  to  provide  support  to  the  RAAF 
Command  Support  Working  Group  in  determining  the  broad  capabilities  required  of 
RAAF  Command  Support  Systems.  The  main  focus  of  the  work  was  to  be  the 
command  chain  from  ACAUST  to  the  OCWG  and  COSQN.  The  requirements  of 
squadrons  were  to  be  addressed  indirectly  through  those  of  wings.  Also  included  in 
the  study  were  Air  Defence,  logistics  and  personnel  aspects  of  Command  Support 
Systems. 

The  specific  objectives  of  the  Task  were  to: 

(i)  Perform  a  context  analysis  of  RAAF  Command  Support  Systems  in  relation  to 
other  ADF  Command  Support  Systems  and  information  systems; 

(ii)  Derive  the  scope  and  terms  of  reference  for  the  Project  Air  5218  -  Air 
Command  Support  System  definition  study; 

(iii)  Determine  the  key  decisions  and  decision-makers  at  a  representative  set  of 
RAAF  Command  Centres; 

(iv)  Determine  the  original  information  sources  along  with  the  information 
sources  and  flows  required  to  support  the  key  decisions  and  decision-makers 
identified  in  (iii); 

(v)  Develop  Prototype  systems  to  elicit  and  validate  information  flows  and  user 
requirements;  and 

(vi)  Propose  a  specification  of  user  requirements  for  RAAF  Command  Support 
Systems. 

Task  Air  93/025  has  three  major  outputs: 

•  A  document  entitled  RAAF  Command  and  Control:  An  Organisational  Analysis 
Perspective  which  summarises  the  findings  of  objectives  (iii)  and  (iv). 

•  A  document  entitled  Prototype  User  Interfaces  for  Future  RAAF  Command 
Support  Systems  and  associated  Prototype  which  presents  the  results  of 
objectives  (v)  and  (vi). 

•  A  document  entitled  Broad  Capabilities  Required  of  RAAF  Command  Support 
Systems.  Final  Report  of  Task  Air  93/025  RAAF  Command  Support  Working  Group 
Study  which  addresses  the  broad  capabilities  required  of  RAAF  Command 
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Support  Systems  and  includes  the  outputs  of  objectives  (i)  and  (ii). 

This  report,  therefore,  constitutes  the  third  of  the  major  outputs  of  Task  Air  93/025. 


1.2.  Aim 

The  aim  of  this  paper  is  to  specify  the  broad  capabilities  required  of  future  RAAF 
Command  Support  Systems. 

1.3.  Changing  Scope  of  Project  Air  5218 

Task  Air  93/025  was  conceived  initially  as  a  precursor  study  to  Project  Air  5218 — ^Air 
Command  Support  System  (ACSS).  Project  Air  5218  is  now  part  of  the  JP2030  project. 
JP2030  is  responsible  for  addressing  Command  Support  System  requirements  at 
strategic  and  operational  level  headquarters. 

When  Task  Air  93/025  was  defined.  Project  Air  5218  planned  to  fund  a  project 
definition  study  for  the  ACSS.  As  the  Major  Capability  Submission  for  Project  5218 
was  refined,  the  additional  need  to  include  the  National  Air  Defence  and  Air  Control 
System  in  the  project  definition  study  for  ACSS  was  identified.  As  a  result,  Task  Air 
93/025  has  not  studied  the  NADACS  in  great  depth,  and  consequently,  NAD  ACS 
issues  may  not  be  represented  fully  in  this  document.  Another  DSTO  study  gives  a 
detailed  assessment  of  the  Air  Defence  Command  and  Control  system  Reference  2 
describes  the  Air  Defence  Command  and  Control  system  and  identifies  several  further 
requirements  for  information  technology  support  in  this  area. 


1.4.  Defining  a  CSS 

There  are  many  definitions  of  a  CSS  in  terms  of  command  and  control  implications  and 
information  systems  aspects.  One  of  the  key  problems  in  building  a  CSS,  in  fact,  is  the 
difficulty  in  defining  what  a  CSS  actually  is. 

The  definition  of  a  CSS  to  be  adopted  by  this  paper  is  that: 

"A  CSS  exists  to  facilitate  the  mission  of  the  organisation" 

Figure  1  presents  the  basic  framework  of  a  CSS  in  support  of  an  organisation's 
mission.  The  mission  for  the  RAAF  can  be  presented  as  the  integration  of  aircraft, 
aircrew,  controllers  and  sensors  performing  particular  air  tasks  at  given  times  from  a 
set  of  bases.  A  CSS  supports  its  conunanders  by  ensuring  that  all  these  assets  and 
elements  are  in  the  right  places  at  the  right  times.  A  CSS  supports  its  commanders 
when  monitoring  these  elements  and  factors  which  may  irtfluence  the  results  of  future 
missions. 

Four  levels  of  fusion  are  required  to  achieve  the  CSS  objectives^. 


1  The  four  levels  of  fusion  presented  in  this  document  should  not  be  confused  with  the  JDL  4 
level  data  fusion  model  which  is  used  for  situation  awareness.  For  more  information  on  the  JDL 
model,  see  E.  Waltz  and  J.  Llinas  "Multisensor  Data  Fusion",  Artceh  House  Inc,  Norwood  MA, 
1990. 
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Figure  1.  Fusion  of  knowledge,  information,  data  and  sensors  are  required  for  the  successful 
execution  of  missions. 


•  Sensor  fusion  is  concerned  with  the  integration  of  irvformation  from  a  range  of 
sensors.  For  example,  the  SADOC  integrates  radar  pictures  from  many 
different  radars  at  different  locations. 

•  Data  fusion  entails  monitoring  the  performance  of  the  mission.  For  the  RAAF, 
data  fusion  consists  of  integrating  data  from  aircraft,  aircrew,  bases  and 
sensors  for  particular  missions  at  particular  times.  Many  people  may  perform 
this  monitoring  at  several  locations  and,  when  their  data  is  fused,  provide 
different  perspectives  of  missions.  For  example,  the  SADC  and  pilots  may 
have  very  different  perspectives  of  the  same  air  defence  mission. 

•  Information  fusion  integrates  all  elements  required  to  perform  missions  at  the 
right  times,  which  requires  information  about  the  availability,  capability  and 
disposition  of  resources,  including  both  own  and  enemy  forces.  Once  a 
mission  has  been  executed,  information  on  the  result  is  required  via  feedback 
loops  and  different  mission  reports  which  confirm  and  maintain  accounting 
details  such  as  resource  usage  figures. 

•  Knowledge  fusion  integrates  all  the  knowledge  employed  to  execute  missions. 
To  cite  an  example,  for  particular  t5q>es  of  mission  it  is  necessary  to  know  the 
capabilities  of  aircraft  and  aircrews,  based  on  the  perceived  importance, 
difficulties,  and  complexities  of  the  mission.  Mission  scheduling  is  shaped  by 
information  on  resources,  their  availabilities  and  capabilities.  For  more 
complex  missions,  co-ordination  will  be  required  between  the  various 
participating  elements.  The  manner  in  which  the  mission  is  performed  may 
be  based  on  SOPs,  but  its  successful  completion  may  require  various 
specialists  to  provide  their  expert  knowledge  on  how  best  to  employ  the 
resources  to  achieve  the  mission. 
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The  data,  information  and  knowledge  required  by  operators  varies  widely  between 
individuals  who  each  have  their  own  expertise,  experiences  and  methods  of  making 
decisions. 

1.5.  Problems  with  the  Current  System 

Current  computer  support  to  RAAF  Command  and  Control  and  the  NADACS  is 
ageing.  Weaknesses  in  the  air  defence  computer  systems  have  revealed  as  a  result  of 
detailed  examination  (Reference  1).  Various  investigations  have  revealed  that 
information  technology  support  in  the  RAAF  Command  and  Control  system 
comprises  a  set  of  disparate  systems  having  little  connectivity. 

The  Basic  Air  Command  Support  System  (BACSS)  is  related  to  the  RAF  Air  Staff 
Management  Aid.  It  is  essentially  a  text-based  bulletin  board  system  which  provides 
rapid  and  secure  communications  to  Secret  level.  Users  of  BACSS  have  criticised  the 
system  on  a  number  of  counts:  it  is  difficult  to  use;  its  availability  is  limited,  and  it  is 
not  compatible  with  the  current  ADFORMS  messaging  system  and  open  systems 
standards.  In  some  measure  the  problem  of  the  BACSS  availability  was  alleviated  by 
the  BACSS  Extension  initiative.  In  a  more  positive  light,  however,  BACSS  can  be 
considered  the  forerunner  of  what  is  now  known  as  Groupware,  that  is,  computer 
software  that  enables  groups  in  widely  disparate  locations  to  interact  and  solve 
problems  co-operatively. 

The  rapid  tasking  of  air  assets  is  essential  for  effective  air  operations.  The  Air 
Headquarters  Tasking  Server  was  introduced  to  provide  a  computer  system  secure  to 
Secret  level  for  operational  taskings  by  ACAUST  and  the  AHQ  Operations  Centre.  As 
well  it  provided  a  secure  database  for  Air  Command  operational  tasks.  This  is  updated 
manually  from  the  message  system,  but  is  without  any  direct  electronic  links  to  the  air 
tasking  systems  of  any  wings  or  squadrons. 

To  integrate  some  of  the  RAAF's  disparate  computer  systems,  the  AHQLAN  project 
has  installed  a  high  bandwidth  secret  LAN  to  deliver  operational,  logistics  and 
administrative  computer  support  to  each  desk  in  AHQ.  Under  the  AHQLAN  project, 
connections  will  be  made  to  remote  systems  using  various  elements  of  the  Defence 
Switched  Data  Network  (DSDN). 

AHQLAN  allows  outputs  from  different  computer  systems  to  be  displayed  on 
individual  workstations.  For  example,  BACSS  and  AHQTS  are  available  from  single 
workstations  but  there  is  still  no  integration  or  interoperation  between  the  systems 
themselves.  Several  other  inadequacies  and  weaknesses  in  the  RAAF  Command  and 
Control  computing  environment  are  listed. 

•  At  present  the  computing  and  communications  infrastructure  to  support  a 
RAAF-wide  Command  and  Control  system  is  inadequate.  Not  all  elements  of 
Air  Command  have  access  to  BACSS. 

•  The  integration  of  sensor  and  data  fusion  occurs  manually  in  the  air  defence 
environment. 

•  Situation  awareness  displays  are  limited  to  the  Recogmsed  Air  Sea  Pictures 
produced  at  the  tactical  level. 
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•  There  is  no  integration  of  data  from  strategic  wide  area  surveillance  assets. 

•  Intelligence  information  to  classifications  of  Secret  or  below  is  limited. 

•  Information  on  logistics,  maintenance  and  persormel  is  stored  on  isolated  ISs, 
hence  does  not  support  operations  directly. 

•  There  is  little  automation  of  any  planning  or  other  decision-making  activities. 

•  Staff  often  have  to  rely  on  telephones  and  voice  or  facsimile  message  systems 
in  order  to  monitor  situations  and  to  gain  information  for  planning— 
however,  BACSS  plays  an  important  role  here. 

•  There  is  no  integration  and  interoperation  of  RAAF  systems  such  as  BACSS, 
AHQTS,  logistics,  computer  maintenance,  and  intelligence  systems. 

•  There  is  no  integration  and  interoperation  of  RAAF  computer  systems  with 
other  ADF  Command  Support  Systems— air  pictures,  however,  may  be 
transmitted  to  Maritime  Headquarters  (MHQ). 

In  summary,  the  computing  and  communications  systems  of  the  RAAF  are  disparate, 
poorly  cormected,  and  inadequately  serviced.  This  inadequate  infrastructure  has  arisen 
through  the  failure  to  acquire  and  orient  these  systems  coherently  towards  achieving 
the  main  objective  of  the  RAAF,  namely,  strategic  and  tactical  air  operations. 

Most  of  the  efforts  and  resources  of  RAAF  CSS  has  been  towards  sensor  fusion 
(NADACS)  and  data  fusion  (AHQTS,  AHQLAN)  tasks.  There  has  been  a  limited 
attempt  at  information  fusion  (BACSS)  and  at  present,  knowledge  fusion  does  not 
receive  any  support  at  all. 

1.6.  The  Wider  CSS  Context 

Several  conunand  support  and  intelligence  support  systems  are  planned  and  have 
been  implemented  within  the  Department  and  the  ADF  (see  Figure  2).  Reference  3 
attempts  to  integrate  these  projects  under  a  common  vision; 

"To  provide  ADF  Commanders  with  an  overview  of  operations  and  the  ability  to 
focus  on  detail  when  required." 

For  intelligence  support,  DIO  will  have  ADFDIS  providing  strategic  intelligence  and 
analytical  tools  to  intelligence  cells  at  strategic  and  operational  level  headquarters. 

The  Joint  Command  Support  Environment  plans  to  develop  computer  support  for 
situation  awareness,  office  automation,  briefing,  information  management,  plaiming, 
decision-making,  and  training.  The  initial  headquarters  planned  for  the  JCSE  are 
HQADF  and  HQNORCOM. 

At  the  operational  level,  each  service  will  have  projects  which  address  the  need  for 
further  computer  support  to  the  command  and  control  functions.  The  physical  co- 
location  of  the  single  service  operational  headquarters  appears  certain  by  the  end  of 
the  century.  The  issue  of  computer  support  for  a  central  co-located  headquarters, 
however,  has  been  addressed  within  the  Department  only  recently. 
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Each  of  the  single  services  have  initiatives  for  providing  their  own  tactical  command 
and  control  systems.  Army  has  spent  many  years  defining  its  requirements  for  a 
Command  Support  System.  AUSTACCS,  in  the  near  future,  will  provide  the  basic 
elements  of  a  Command  Support  System  for  its  land  operations.  Navy  has  procured 
their  fleet  Command  Support  System  from  overseas,  a  system  which  has  provided 
them  with  interoperability  with  other  allied  nations.  Future  initiatives  for  the  maritime 
area  would  suggest  that  similar  and  more  advanced  technologies  will  be  produced 
through  our  indigenous  capabilities.  For  the  RAAF  CSS  to  operate  in  a  joint 
environment,  the  minimum  level  of  interoperability  is  data  fusion.  That  is,  the  RAAF 
CSS  must  be  capable  of  sharing  all  t3q>es  of  data  with  the  CSSs  of  the  other  services.  To 
perform  joint  operations,  however,  the  minimum  level  of  interoperability  required  for 
the  RAAF  CSS  is  information  fusion,  that  is,  the  RAAF  CSS  must  be  capable  of  sharing 
and  integrating  all  the  elements  required  to  perform  missions.  As  well,  the  role  of  the 
RAAF  CSS  at  a  joint  headquarters  must  be  supported  by  its  capability  to  perform 
knowledge  fusion,  that  is,  the  RAAF  CSS  must  be  capable  of  sharing  and  integrating 
all  the  knowledge  required  to  plan  and  perform  in  joint  operations. 
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Figure  2.  Command  support  and  intelligence  support  within  the  Department  and  the  ADF. 

Shaded  boxes  represent  those  hierarchical  elements  which  may  be  included  in  a  co¬ 
located  joint  headquarters. 


1.7.  Approaches  to  Broad  Capabilities 

The  ADF  Command  and  Control  Information  Systems  Plan  (Reference  3)  was 
developed  with  an  appreciation  that  the  problem  domain  is  ever  dynamic  and; 

"The  user  requirement  for  a  CSS  is  never  static,  and  will  always  evolve  with 
experience." 

This  document  was  not  planned  as  a  user  requirement  specification— this  is  because 
the  user  requirements  for  RAAF  CSSs  will  change  from  the  time  this  document  was 
written  until  the  ACSS  becomes  operational. 
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Most  user  reqmrement  documents  attempt  to  reduce  the  task  to  its  functional  and 
non-fxmctional  requirements.  A  simple  functional  classification,  however,  often  fails  to 
capture  many  of  the  complexities  of  Command  Support  Systems,  and  the  arbitrary 
reduction  into  functional  and  non-fimctional  requirements  often  fails  to  consider  the 
rapid  progress  of  modem  technologies. 

Even  though  user  requirements  change  as  they  are  dependent  on  current  situations, 
along  with  the  styles,  personal  preferences  and  experiences  of  the  individual 
commanders,  the  general  requirements  or  broad  capabilities  of  CSSs  can  be  defined. 

The  main  functions  of  a  CSS,  as  highlighted  by  Reference  3,  are  to: 

•  Display  an  integrated  Common  Situation  Picture.  This  may  be  described  as  the 
situation  monitoring  and  awareness  function  which  tracks  the  statuses  of 
friendly,  enemy  and  neutral  forces,  and  which  locates  events  of  military  or 
political  significance  in  their  geographical  and  other  contexts. 

•  Disseminate  data  and  information  to  other  headquarters  and  authorised 
organisations.  This  is  referred  to  as  an  information  management  and 
communications  function  for  message  and  data  transmission  or  reception.  It 
may  be  supplemented  also  by  an  ability  to  store  messages  and  data  and  to 
retrieve  them  rapidly  as  required. 

•  Assist  planning  and  decision-making.  Planning  aids  are  tools  which  enable 
commanders  to  perform  appreciations  of  situations  and  to  plan  the  allocation 
of  necessary  assets  to  meet  emerging  threats. 

•  Facilitate  briefings  to  RAAF  commanders  and  other  agencies,  namely,  the 
ability  to  display  current  situations,  assessments  and  plans  in  a  manner 
suited  to  RAAF,  other  ADF,  Government  and  civil  personnel. 

•  Provide  simulation  for  staff  training,  that  is,  the  ability  to  operate  the  system 
using  information  from  computer-generated,  rather  than  real,  events  and 
actions. 

•  Provide  office  automation,  comprising  word  processing,  spreadsheet, 
presentation  and  e-mail  applications. 


The  broad  capabilities  of  Command  Support  Systems  have  been  defined  in  such  a 
way  that  the  user  requirements  themselves  can  change. 

When  defining  the  broad  capabilities  required  of  future  RAAF  Command  Support 
Systems,  DSTO  has  emphasised  the  architecture  necessary  to  support  the  main 
purpose  of  the  organisation — ^in  this  case  the  RAAF's  strategic  and  tactical  air 
operations — ^all  within  an  environment  that  is  dynamic  and  changing  constantly. 
Flexible  systems  are  required  which  support  individual  and  team-based  decision¬ 
making  in  distributed  organisations  and  in  widely  different  situations. 

This  approach  has  been  adopted  for  several  reasons: 

(i)  Computing  hardware  manufacturers  have  made  a  firm  commitment  to  open 
systems  and  common  standards,  with  the  result  that  the  cost  of  hardware  is 
falling  rapidly. 
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(ii)  In  communications/  increased  capacities  have  become  available  through 
efficient  switching  and  bandwidth  allocations,  with  the  result  that  the  cost  of 
communications  is  also  falling  rapidly; 

(iii)  The  major  challenges  facing  organisations  in  the  future  will  be  developing 
smart  applications  capable  of  using  communicatior\s  and  IS  infrastruchires; 

(iv)  Although  basic  requirements  can  be  defined,  user  requirements  are  changing, 
creating  a  demand  for  envirorvments  that  supports  such  changes;  and 

(v)  It  is  users,  not  professional  software  developments,  who  are  driving  the 
development  of  smarter  applications. 

2.  Overview  of  Capabilities  Identified 

Command  Support  System  capabilities  as  distinct  from  IS  implementation 
requirements,  have  been  emphasised.  Separating  such  Command  Support  System 
issues  from  IS  implementation  issues  highlights  the  precise  business  supported  by  a 
CSS.  It  enables  effort  to  be  concentrated  on  what  is  specific  to  RAAF  CSSs,  for  example, 
rather  than  on  logistics  or  Army  CSSs. 

2.1.  CSS  Capabilities 

Three  important  concepts  describe  the  broad  capabilities  required  of  CSSs. 

CSS  Concept  1 

Commanders  generally  operate  in  environments  characterised  by  incomplete, 
inconsistent,  uncertain  and  equivocal  information.  As  well,  the  information 
requirements  of  individual  commanders  depend  on  their  individual  backgrounds  and 
the  situations  at  hand.  The  information  requirements  of  individuals  in  given  situations 
cannot  be  pre-specified  completely.  This  is  why  it  is  important  for  commanders  to 
tailor  and  vary  their  information  requirements  as  situations  change. 

CSS  Concept  2 

The  work  tasks  may  be  performed  by  agents  which  have  the  necessary  knowledge  of 
tasks,  the  required  information,  the  tools  to  manipulate  the  information,  and  the 
information  suitably  formatted  to  facilitate  its  use  in  performing  the  tasks.  Tools,  tasks, 
information  and  representations  change  over  time,  however,  and  hence  users  also  need 
the  means  to  transform  their  tools,  representations,  information  and  tasks  to  meet 
changing  requirements  in  situations  which  are  themselves  transforming. 

CSS  Concept  3 

Typical  commanders  operate  in  computer  environments  which  represent  the  purpose 
and  functions  of  their  organisations,  their  access  to  tools,  information,  tasks  and 
views — all  provided  in  an  organisational  context.  Commanders  also  need  to  complete 
their  tasks  independently  of  any  IS  implementation  considerations. 
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The  broad  capabilities  required  by  a  CSS  at  the  highest  level  can  be  stated  in  concise 
terms. 

•  A  CSS  should  support  users  in  performing  their  key  business  processes  of 
command  and  control. 

•  A  CSS  should  facilitate  the  organisation  in  executing  its  operational  missions. 

•  A  CSS  should  support  users  in  performing  their  roles  in  organisational  and 

situational  contexts. 

•  A  CSS  should  support  formal  and  informal  flows  of  information  and 
knowledge. 

•  A  CSS  should  support  the  workings  of  individuals,  groups  and  organisations. 

•  A  CSS  should  provide  an  environment  which  develops,  changes  and  tailors 

its  user  requirements  over  time. 

2.2.  IS  Capabilities 

Two  important  concepts  describe  the  broad  capabilities  required  of  ISs. 

IS  Concept  1 

Governments  and  industry  have  addressed  the  wide  issue  of  IS  integration  and 
interoperation,  and  standards  have  emerged  which  enable  ISs  to  interoperate  and  to 
provide  the  functionality  required  by  users.  ISs  which  can  interoperate  will  provide  all 
non-business-specific  support. 

IS  Concept  2 

Users  will  tailor  and  develop  applications  through  what  is  termed  a  distributed  object 
management  system.  All  tasks,  views,  information  and  tools  therein  are  regarded  and 
processed  as  objects  which  can  be  stored  on  a  number  of  computers.  The  distributed 
object  management  system  retrieves  tasks,  tools,  information  and  views — 
transparently  for  users.  Users  are  aware  that  the  global  or  virtual  object  space  contains 
the  tools,  views,  information  and  tasks  which  are  required,  retrieved,  and  processed  by 
them. 

The  broad  capabilities  required  by  an  IS  can  be  stated  at  the  highest  level  in  a  few 
concise  statements. 

•  IS  interoperation  permits  ISs  to  co-operate  when  executing  tasks  jointly. 

•  IS  development  should  follow  an  object-oriented,  open,  standards-based 
approach  to  systems. 

•  IS  development  should  include  middleware  to  provide  a  high-level  platform- 
independent  environment  for  the  development,  maintenance,  and  run-time 
support  of  distributed  applications. 

•  IS  development  should  adopt  the  architectures  and  standards  necessary  for 
distributed  object  management. 
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3.  User  Organisation 

The  current  user  organisation  is  documented  extensively  in  Reference  4,  and  an 
overview  only  will  be  given  here. 

The  focus  of  ACSS  is  the  command  chain  from  ACAUST  to  OCWG  to  COSQN.  The 
important  role  of  the  SADC  chain  of  command,  and  the  roles  of  Group  Commanders 
needs  to  be  stated  concisely.  Nor  will  all  command  chains  necessarily  always  include 
Commanders — only  those  with  the  assets  required  to  meet  current  threats  are 
required.  As  well,  the  actual  personnel  numbers  in  the  organisation  and  the  relative 
numbers  required  will  change  constantly  as  the  threat  ebbs  and  flows  in  the  transitions 
between  peacetime  and  wartime  activities.  The  roles  performed  by  those  in  the 
command  chain  and  their  support  staff  will  vary  markedly  as  situations  change.  The 
number  of  people  performing  key  roles  will  also  change  in  order  to  meet  varying 
demands. 

Identifying  the  users  of  future  systems  is  often  seen  as  essential  to  user  requirement 
specifications.  Users  of  systems  need  to  be  represented  in  more  than  just  the 
requirement  specifications.  As  operators  of  software  alone,  they  are  an  integral  part  of 
any  Command  Support  System. 

The  typical  roles  which  users  perform  in  headquarters  are  those  which  are  required 
regularly.  Threat  situations  may  arise,  however,  which  necessitate  that  further 
expertise  is  brought  into  the  headquarters — such  short-term  expertise,  for  example, 
may  be  gathered  through  informal  communication  with  other  headquarters.  Longer- 
term  expertise  may  be  acquired  through  defining  and  creating  special  roles  within 
headquarters  and  fulfilling  the  requirements  of  those  new  roles. 

Roles  are  refined  and  changed  over  time.  The  users  of  future  systems  should  be  able 
to  adapt  and  change  their  roles  within  their  organisations,  therefore,  to  meet  the 
changing  demands  of  their  intentions  and  enterprises. 

ACSS  should  provide  software  which  represents  users  in  terms  of  their  roles  in  their 
organisations.  The  specification  of  these  roles,  which  are  changing  and  are  not  fixed, 
should  be  a  dynamic  process.  As  these  roles  change,  an  ACSS  should  have  the 
flexibility  to  accommodate  these  changes. 

As  part  of  Task  Air  93/025,  the  various  roles  performed  within  the  RAAF  Command 
and  Control  system  were  identified  and  analysed.  For  each  such  role,  the  tasks,  the 
tools,  the  information  and  the  necessary  representation  of  such  information  were  all 
specified.  Many  advantages  are  gained  from  such  representations;  for  example,  the 
flexibility  to  define  pre-specified  routine  tasks  and  to  perform  additional  tasks 
concurrently  to  meet  unusual  situations  can  be  designed  into  such  command  and 
control  systems.  For  a  more  in-depth  discussion,  see  Reference  4. 
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4.  Command  Support  System  and  Information 
System  Characteristics 

Developing  the  next-generation  RAAF  Command  Support  System  presents  many 
challenges.  For  example,  the  procuring  of  a  turn-key  system  to  enhance  current 
capabilities  is  no  longer  regarded  as  feasible  or  economically  viable.  As  there  has 
already  been  some  progress  in  providing  information  technology  support  to  command 
and  control,  a  clear  path  has  to  be  set  for  the  migration  from  the  current  legacy  to 
future  capabilities. 

The  Command  Support  Systems  of  the  single  services  are  neither  monolithic  nor 
isolated.  Instead,  they  comprise  many  of  the  building  blocks  of  a  wider  Defence  Force 
network.  Interoperability  of  computer  systems  through  military  message  systems  is  no 
longer  sufficient  to  support  such  a  diversity  of  new  media,  such  a  quantity  of 
information  or  so  many  complex  networks  operating  concurrently  in  future  ISs.  Many 
of  our  current  concepts  of  interoperability  are  simplistic  and  require  urgent  review. 

Nor  can  the  current  heavy  investment  in  information  technology  continue  without  a 
clear  statement  of  a  business  case.  Information  technologies  need  to  be  aligned  more 
closely  to  the  main  businesses  of  organisations  so  that  their  assets  and  leverage  can  be 
maximised.  The  main  business  of  the  RAAF  is  expressed  in  the  statement  (reference  5): 

"To  conduct  effective  strategic  and  tactical  air  operations  as  an  independent  force,  or 
part  of  a  joint  or  combined  force,  in  the  pursuit  of  Australia's  defence  and  national 
interests." 

The  key  concept  throughout  this  Section  is  that  a  central  IS  architecture  can  provide 
the  essential  computing  and  communications  services  for  a  RAAF  CSS.  Extending  the 
actual  CSS  architecture  are  the  computing  applications  and  services  which  support  the 
main  business  processes  of  the  RAAF. 

4.1.  CSSs  and  ISs 

At  present  the  RAAF  has  several  computer  systems  which  support  specialist  areas.  For 
example,  CAMM2  supports  aircraft  maintenance  and  the  AHQTS,  and  air  tasking. 
These  systems  have  developed  in  isolation,  however.  Several  use  proprietary  hardware 
and  software  applications,  and  essentially  "stove-pipe"  information  to  terminals.  It  is 
noted  that  the  business  applications  of  the  system  have  become  entwined  with  the  IS 
aspects,  which  places  enormous  stresses  on  users  who  find  they  must  be  aware  of  each 
IS  they  use  in  order  to  benefit  from  them. 

AHQLAN  has  attempted  to  make  existing  systems  appear  less  dysfimctional  by 
enabling  users  to  access  several  systems  from  single  workstations.  Users  have  to  learn 
how  to  operate  a  number  of  very  different  ISs,  however,  and  have  found  they  spend 
less  time  on  performing  actual  work. 

Figure  3  presents  the  ciurent  position  in  terms  of  IS  developments  and  how  we 
presently  view  a  CSS,  logistics  system,  maintenance  system  and  other  computing 
systems.  For  the  RAAF,  a  CSS  is  a  collection  of  ISs  which  provide  very  limited  support 
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to  users.  The  reasons  for  this  limited  support  have  resided  in  the  challenges  of  bringing 
about  IS  integration  and  interoperation  and  in  the  difficulties  of  separating  command 
support  applications  development  from  IS  implementation. 

The  development  of  computer  systems  for  logistics  and  maintenance  has  been  more 
successful  than  that  for  Command  Support  Systems.  This  is  attributed  to  the  clearer 
definitions  of  information  space  for  these  functions,  and  the  fact  that  the  tasks  which 
the  system  supports  are  relatively  straightforward,  well  defined,  and  often  highly 
repetitive  and  unvarying  from  one  situation  to  another. 


The  information  spaces  of  Command  Support  Systems,  however,  are  more  complex 
and  abstract,  hence  poorly  defined.  Some  aspects  of  command  support  are  repetitive 
and  do  not  demonstrate  much  variation  from  situation  to  situation.  CSS  is  often 
confronted  with  rapidly  changing  situations,  limited  information  about  threats  to  be 
met,  along  with  internal  constraints  such  as  shortages  of  replacement  parts  for  aircraft. 
Essentially,  command  and  control  is  the  system  to  enable  the  reorganisation  of  one's 
forces  in  the  face  of  emerging  threats.  If  the  assessment  of  the  threat  or  current  force 
capability  and  sustainability  is  incorrect,  however,  then  command  and  control  has 
failed. 
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Figure  3.  Characteristics  of  current  computer  system  development— ^tove-piped  computer 
systems  which  do  not  separate  business  applications  from  IS  implementation. 


On  the  principle  that  the  application  of  knowledge  is  itself  a  form  of  knowledge,  a 
Command  Support  System  requires  not  only  access  to  information  on  emerging 
situations  but  also  access  to  knowledge  which  is  capable  of  interpreting  said 
information  intelligently.  Currently  this  knowledge  is  provided  by  people  within  the 
command  chain  whose  rapid  informal  communication  of  knowledge,  therefore,  is  vital 
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to  the  operation  of  command  and  control.  In  the  future,  such  knowledge  may  be  stored 
within  the  computer  itself  as  smarter  applications. 

IS  integration  and  interoperation  has  been  addressed  widely  by  governments  and 
industry.  Standards  are  emerging  which  will  enable  ISs  to  collaborate  and  interoperate 
to  provide  the  functionality  which  users  require.  For  example,  all  non-business-specific 
support  will  be  provided  by  ISs  capable  of  interoperating— a  development  with 
several  important  consequences: 

(i)  Business  areas  with  poorly-defined  information  spaces  can  access  systems  on 
an  as-required  basis; 

(ii)  End  users  will  not  have  to  know  which  computer  systems  they  are  using; 

(iii)  Applications  can  be  developed  independently  of  individual  IS 
implementation  details;  and 

(iv)  The  business  aspects  of  organisations  can  be  separated  from  the  IS 
implementation  aspects. 


Figure  4  shows  how  IS  interoperation  offers  a  different  perspective  of  Command 
Support  Systems.  Embracing  the  ideal  of  ISs  interoperation,  for  example,  allows  us  to 
view  Command  Support  Systems  separately  from  the  generic  aspects  of  ISs.  This 
maintains  the  focus  on  the  real  purpose  of  the  system— the  business  of  the 
organisation. 
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Figure  4.  Characteristics  of  future  computer  systems — business  support  is  independent  of  IS 

implementation. 
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4.2.  Concepts  for  RAAF  Command  and  Control  Application 
Development 

The  general  approach  necessary  for  command  support  to  adopt  interoperable  IS 
principles  which  permits  end  users  to  tailor  and  change  their  requirements  are  shown 
in  Figure  5.  Central  to  the  overall  concept  are  intelligent  agents  or  people  capable  of 
performing  one  or  more  roles  in  organisations.  In  order  to  complete  their  tasks, 
intelligent  agents  require  information,  tools  to  manipulate  that  information,  and 
knowledge  of  their  tasks  to  be  performed  individually  or  as  members  of  teams.  Given 
such  tasks,  the  information  also  needs  to  be  represented  clearly  for  its  maximum  and 
rapid  comprehension. 

In  a  world  of  interoperable  ISs,  end  users  will  face  huge  spaces  of  information,  tools, 
tasks  and  views.  To  maximise  their  use  of  such  spaces,  both  information-push  and 
user-pull  techniques  will  be  required. 

Traditional  computer  systems  were  built  on  the  basis  that  information  is  pushed  to 
the  user.  Information  flows  were  designed  and  implemented  so  that  information  was 
received  by  the  people  suitably  concerned  at  the  right  time.  Such  an  approach  has  been 
adequate  during  standard  situations,  but  has  not  assisted  users  to  cope  with  often 
threatening  changes  in  their  environments. 

User-pull  has  been  identified  as  an  answer  to  assisting  users  to  find  the  information, 
tools,  tasks  and  views  necessary  for  dealing  with  new  rapidly-evolving  situations. 
User-pull,  however,  is  not  as  straightforward  as  it  first  appears.  A  question  is:  How  do 
users  learn  what  they  will  need  to  know  and,  more  importantly,  where  and  how  to 
find  out  what  they  need  to  know?  Much  of  this  work  could  be  carried  out  co-operating 
through  ISs  wherein  users'  inquiries  are  processed  co-operatively  and  efficiently  by 
users  at  often  disparate  locations.  As  well,  users  may  want  to  navigate  efficiently 
through  the  support  system  to  determine  the  availability  of  information,  tools,  tasks, 
and  views,  as  they  perform  their  roles. 
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Figure  5.  End  user  concepts  for  RAAF  Command  and  Control  development. 

Achieving  a  balance  between  information-push  and  user-pull  is  central  to  designing 
successful  systems.  The  information-push  aspect  of  the  system  should  permit 
changes — ^the  information  regarding  even  standard  situations  requires  alteration  from 
time-to-time.  Information-push  in  an  interoperable  environment  would  be  supported 
through  the  roles  which  users  adopt  and  perform.  Roles  would  be  defined  which 
specify  the  tasks,  the  information,  the  tools  and  the  views  which  users  need  to 
integrate  and  operate  in  order  to  fulfil  such  roles.  However,  such  definitions  could  be 
flexible  and  modified  by  users  as  new  information  becomes  available  and  modifies 
such  roles  as  required. 

A  starting  point  for  the  information,  tasks  and  tools  required  by  the  RAAF  Command 
Support  System  has  been  defined  in  the  publication  entitled  RAAF  Command  and 
Control:  An  Organisational  Analysis  Perspective  (see  reference  4).  For  ACSS,  several  tools 
can  be  identified  which  may  be  classified  broadly  according  to  the  categories  of 
distributed  decision-making,  situation  awareness,  situation  assessment  and  planning  and 
training. 

4.2.1.  Distributed  Decision-making  Tools 

Distributed  decision-making  tools  address  such  questions  as:  How  is  expertise  or 
special  knowledge  to  be  integrated,  from  users  and  personnel  who  are  geographically- 
separated,  and  brought  to  bear  when  making  decisions?  How  is  a  give-and-take 
envirorunent  for  discussion  and  argument  achieved  for  making  decisions  in  which 
participants  are  not  physically  co-located?  How  is  a  real-time  shared  information  space 
created  for  physically-separated  personnel?  How  are  team  work  and  collaborative 
activities  to  be  encouraged?  How  can  common  situation  and  status  pictures  be 
provided  for  groups  separated  in  time  and  space? 
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The  tools  listed  below  enable  a  system  to  be  established  and  maintained  so  that  it  can 
manage  the  organisation  and  its  workflows  and  permit  users  to  work  in  ways  that  are 
collaborative  and  dynamic.  The  system  also  helps  users  to  find  the  information,  the 
tools  and  the  expertise  which  they  need  to  meet  evolving  situations  for  the  first  time. 

•  The  Organisational  Tool  is  provided  to  create,  maintain  and  update  the 
organisation.  It  can  also  define  the  basic  activities  of  the  organisation,  its 
structure,  and  its  available  resources.  Commanders'  goals  can  be  set, 
priorities  allocated,  strategies  defined,  workflow  models  prepared,  feedback 
loops  set  in  place,  assets  registered,  and  navigation  tools  activated. 

•  The  Function  Tool  can  create,  maintain  and  update  functions  based  on  an 
evolving  organisational  framework.  The  Function  Tool  is  used  to  define  tasks, 
information,  tools,  views,  to  design  basic  workflow  models,  to  set  feedback 
loops,  and  to  register  all  properties  with  the  Navigation  Tool. 

•  The  Organisation  Unit  Tool  creates,  maintains  and  updates  the  organisation 
units  based  on  the  organisation  framework.  The  Organisation  Unit  Tool 
allocates  the  tasks  and  intelligent  agents  to  fulfil  the  roles  set  by  the 
organisational  framework.  It  develops  the  structure  of  the  organisation 
framework  such  that  new  organisation  units  and  functional  cells  are  added, 
new  workflow  models  designed,  added  and  maintained,  feedback  loops  set, 
and  new  tasks,  information,  tools  and  roles  set,  obtained  and  defined  within 
the  functional  cells  as  all  these  are  required,  and  all  properties  are  registered 
with  the  navigation  tool. 

•  The  Role  Tool  maintains  and  updates  the  workflows  based  on  the  evolving 
orgarusation  unit  framework.  It  uses  the  organisation  unit  framework  to 
allocate  resources  and  tasks.  It  adds  and  maintains  workflow  models  and 
feedback  loops,  and  registers  all  properties  with  the  navigation  tool. 

•  The  Navigation  Tool  creates,  maintains  and  updates  the  overall  properties  of 
the  system.  It  is  used  to  guide  users  through  the  organisation,  to  observe  its 
structures,  and  the  roles  performed,  along  with  the  allocation  of  information, 
tools  and  tasks. 

•  The  Workflow  Tools  creates,  maintains  and  updates  the  flows  of  information 
and  work  through  the  organisation.  This  tool  integrates  the  tasks  performed 
by  different  roles,  and  associates  the  timing  and  relationships  between  task 
performances. 

•  The  Meeting  Tool  generates  agendas,  records  the  proceedings  and  decisions  of 
meetings,  and  allocates  resulting  actions. 

•  The  Briefing  Tool  generates  and  presents  briefing  material  in  the  most  suitable 
media. 

•  The  Communication  Tool  generates,  maintains  and  updates  messages.  It  may 
be  used  to  format  messages  or  personal  communications.  In  this  way  it 
supports  interactive,  multimedia  conversations  as  well  as  simplex 
communications. 

•  The  Desktop  Tool  generates,  maintains  and  updates  individual  information, 
tools,  tasks  and  views. 
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•  The  Sharing  Tool  stores  and  displays  information,  tools  and  views  common  to 
groups  of  users.  Such  stores  and  displays,  for  example,  include  shared 
workspaces  and  electronic  blackboards. 

•  The  Document  Tool  generates,  maintains  and  updates  document-based 
information  sources  such  as  reports,  directives,  and  plans. 

4.2.2.  Situation  Awareness  Tools 

Situation  awareness  tools  are  designed  to  provide  users  with  information  and 
awarenesses  in  response  to  questions  which  may  be  classified  in  four  main  categories: 

(i)  Surveillance  awareness.  Where  are  my  sensors?  What  is  their  availability?  What 
is  their  coverage?  What  can  I  see?  How  old  is  the  data?  What  is  the  required 
sampling  rate  for  each  battlefield  area,  target  type,  and  sensor  type? 

(ii)  Enemy  awareness.  Who  is  the  enemy?  Where  is  the  enemy?  What  is  the  enemy 
doing?  What  are  they  trying  to  make  me  think  they  are  doing?  What  is  their 
probable  intent?  What  are  their  capabilities  and  constraints?  What  do  their 
doctrine  and  tactics  dictate?  What  is  the  weather,  terrain,  logistics?  What  lines 
of  communication  exist? 

(iii)  Own  force  awareness.  Where  are  my  own  forces?  What  are  their  current 
strengths  and  vulnerabilities?  What  are  their  current  missions?  Can  they  be 
diverted?  What  about  weather  and  terrain?  What  lines  of  communication 
exist?  Is  electronic  warfare  likely? 

(iv)  Specialist  capabilities  awareness.  What  about  special  capabilities  and 
employment  of  UAVs,  space,  remote  imagery,  JORN? 

Several  tools,  which  may  be  classified  as  situation  awareness  tools,  are  also  required. 

•  The  Mapping  Tool  displays  cartographic  information.  This  includes  the  ability 
to  select  geographical  areas,  along  with  the  capability  to  zoom  in,  zoom  out, 
pan  up,  down,  left  and  right  on  a  map  capable  of  displaying  centres  of 
population,  roads,  railways,  airports,  ports,  political  boundaries,  rivers, 
terrain,  detailed  topographies,  and  weather. 

•  The  Asset  Distribution  Tool  displays  the  locations  of  own,  enemy  and  neutral 
force  assets,  and  assessments  of  likely  unknown  bases,  aircraft  and  radar 
installations. 

•  The  Asset  Capability  Tool  displays  the  capabilities  of  aircraft,  bases,  sensors 
and  organisations. 

•  The  Airspace  Management  Tool  displays  the  positions  of  CAP,  tankers  and 
AEW&C,  sectors,  ADIZ,  beyond  visual  range  zones,  missile  engagement 
zones,  and  safe  corridors. 

•  The  Data  Fusion  Tool  correlates  and  associates  data,  in  particular  sensor  data, 
to  enrich  views  and  interpretations  of  current  events. 

•  The  Information  Fusion  Tool  correlates  and  associates  data  and  provides  an 
enriched  interpretation  of  current  events,  particularly  in  the  areas  of  multi¬ 
sensor,  plans  and  intelligence  data. 
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•  The  ROE  Tool  selects,  generates,  maintains  and  updates  the  current  and 
possible  Rules  of  Engagement. 

•  The  Log  Tool  creates,  maintains  and  updates  reports  of  events  as  they  develop. 
The  Log  Tool  permits  events  to  be  sorted  by  date,  time,  place  and  location  or 
by  other  user-defined  properties. 

•  The  History  Tool  places  events  in  chronological  order. 

•  The  Time  Tool  displays  situation  information  at  specified  points  in  time, 
presents  the  flows  of  assets  over  specified  periods  of  time,  and  offers  stepped 
views  through  situations  in  pre-defined  intervals. 

•  The  Pattern  Recognition  Tool  absorbs  data  on,  and  notices  patterns,  trends,  and 
unusual  occiurrences  in  data  on  a  wide  range  of  information  sources 
including  location  of  assets,  emitter  frequencies  and  numbers,  tracks, 
situations  and  equipment  failures. 

•  The  Availability  Tool  generates,  maintains  and  updates  the  allocation  and 
current  usage  of  resources. 

•  The  Board  Tool  generates,  maintains  and  updates  tabular  information.  It  is 
used  to  activate  and  direct  alert  information,  aircrew,  maintenance,  tasking, 
flying  programs,  and  exercise  programs. 

4.2.3.  Situation  Assessment  and  Planning  Tools 

Situation  assessment  and  planning  tools  are  provided  to  answer  questions  such  as 
What  can  the  enemy  do  next?  What  are  the  constraints  over  the  enemy?  What  can  I  do 
next?  What  are  the  constraints  over  me?  How  much  time  do  I  have?  What  are  my 
risks?  What  are  the  enemy's  risks?  What  are  my  real  options?  What  if  I  do  this?  What  if 
the  enemy  does  that?  How  fast?  How  far? 

•  The  Change  Tool  detects  and  highlights  the  differences  between  the  situation 
information  and  expectations. 

•  The  Plan  Activities  Tool  generates,  maintains  and  updates  the  static  graphical 
representation  of  activities. 

•  The  Plan  Execution  Tool  generates,  maintains  and  updates  the  dynamic 
representation  of  activities. 

•  The  Time  and  Space  Tool  calculates  the  spatial  and  temporal  relationships 
between  items  of  nominated  information. 

•  The  Air  Space  Control  Planning  Tool  assesses  best  routes,  manages  air  space, 
and  deconflicts  missions. 

•  The  Force  Allocation  Tool  allocates  possible  assets  to  planned  activities. 

•  The  Target  Assignment  Tool  assigns  aircraft  to  targets  and  specifies  the 
destruction  requirements. 

•  The  Weapon  Assignment  Tool  allocates  weapons  to  aircraft. 

•  The  Communications  Planning  Tool  allocates  bandwidths  and  channels. 
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The  Electronic  Warfare  Planning  Tool  allocates  tasks  and  their  frequencies  of 
completion. 

The  Simulation  Tool  plans  real  time  and  fast  simulation  activities. 

The  Plan  Comparison  Tool  detects  and  highlights  different  planning  options. 

The  Sustainability  Tool  generates,  maintains,  updates,  and  projects  the  use  of 
resources. 


The  essential  activity  of  situation  assessment  and  planning  is  the  direction  and 
control  of  forces.  Force  direction  and  control  often  requires  the  modification, 
replanning  and  restructuring  of  missions,  along  with  any  necessary  retargetting  and 
rescheduling  of  aircraft — activities  inherent  to  the  development  of  situation  assessment 
and  planning  tools. 

4.2.4.  Training 

A  Command  Support  System  should  support  both  peacetime  and  contingency 
operations,  both  of  which  require  training  in  the  use  of  software.  Contingency 
operations  are  more  exacting,  however,  and  should  be  exercised  frequently. 

These  training  tools  are  designed  to  exercise  individual  and  team-based  decision¬ 
making  through  a  series  of  exercises  which  increase  the  load  and  sophistication  of 
duress  for  operators  and  decision-makers.  Such  training  exercises  improve  the 
qualities  of  workflows  devised  and  tasks  allocated  for  personnel  and  equipment  by 
trialing  "what  if"  scenarios.  The  Scenario  Generation  Tool,  which  scripts  such 
exercises,  can  combine  both  real-world  and  exercise  data.  In  turn,  the  Scenario 
Execution  Tool  is  capable  of  freezing  exercise  data  so  that  it  may  be  re-examined  and 
assessed,  so  that  responses  to  real-time  information  can  be  improved. 

4.3.  A  Master  Architecture 

A  future  Command  Support  System  for  the  RAAF  must  be  developed  within  the 
confines  of  sotmd  technical  and  domain  frameworks.  A  master  architecture  provides  a 
framework  in  which  policies,  concepts  and  implementation  issues  can  be  integrated.  A 
domain  framework  is  presented  reference  4.  A  technical  framework  is  presented  in 
Section  4.4  of  this  document. 

Figure  6  shows  a  master  architecture  composed  of  the  following  6  levels; 

•  The  Global  Level  addresses  IS  issues  which  apply  worldwide,  such  as  industry 
standards  and  the  use  of  commercial-off-the-shelf  (COTS)  products  and 
services.  Use  and/or  tailoring  of  COTS  products  is  seen  as  cost-effective  as  it 
reuses  and  builds  upon  hard-earned  expertise.  However,  relatively  few  COTS 
products  and  services  specifically  meet  the  needs  of  Command  Support 
Systems.  The  integration  and  updating  of  COTS  products,  therefore,  could 
prove  problematic. 

•  The  System  Level  provides  strategic  and  corporate  guidance  for  the 
development  of  Command  Support  Systems.  As  well  it  provides  information 
storage,  systems  interoperation  and  security.  Corporate  ISs  guidance  includes 
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such  initiatives  as  the  Government  Open  Systems  Interconnection  Profile 
(GOSIP)  for  command  and  control  along  with  any  specialisations  required  for 
RAAF  interconnection. 

The  Mission  Level  aspects  are  those  which  address  the  business  of  the 
organisation.  Business  re-engineering  is  the  "radical  redesign  of  existing 
business  processes  to  achieve  efficiency  and  better  services".  The  re¬ 
engineering  of  business  process,  therefore,  flows  from  the  identification  of  the 
central  business  processes  of  the  organisation.  For  RAAF  Command  and 
Control  these  are:  operations,  management,  logistics,  intelligence,  liaison, 
plans  and  administration. 

It  is  useful  to  relate  the  main  business  processes  of  an  organisation  to  the 
key  activities  performed  by  the  enterprise.  For  example,  performance  logistics 
means  little  unless  the  purpose  of  the  logistics  is  included— in  the  case  of  the 
RAAF,  management  for  air  defence  operations. 
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Figure  6.  A  master  architecture  for  RAAF  IS  and  CSS  development. 


The  Task/Function  Level  addresses  the  automation  of  business  processes.  The 
re-engineering  of  business  processes  can  be  achieved  by  simple  functional 
decomposition.  Functions  are  mapped  from  the  existing  business 
environment  onto  computer  functions  or  new  ISs.  Another  way  to  represent 
business  processes  is  through  the  use  of  tasks.  Tasks  can  range  from  simple 
physical  tasks  to  complex  cognitive  ones.  Usually  they  are  performed  in  some 
time  sequence,  some  with  more  complex  representations  which  result  in 
parallel  branching  of  actions  and  which  present  associated  requirements  for 
synchronisation  planning.  Task  performance  and  business  processes  also 
change  over  time,  which  means  that  future  systems  should  be  able  to 
represent  tasks  and  functions  explicitly  so  that  these  may  be  developed 


20 


dynamically,  possibly  even  radically,  as  tasks  are  tailored  to  meet  changing 
situations. 

•  The  Tool  Level  addresses  and  monitors  the  support  provided  through  the 
automation  of  tasks.  This  level  is  sometimes  called  the  application  level.  An 
application  is  usually  a  software  program  or  suite  of  programs  developed  to 
process  particular  functions  within  organisations.  Applications  are  rarely 
modified  easily,  so  that  it  is  the  use  of  tools  rather  than  of  applications  in 
future  ISs  which  will  assist  users  to  identify  the  true  constituents  of  software 
applications.  At  present,  such  applications  perform  relatively  simple  tasks. 

For  example  the  tool  of  a  spreadsheet  application  provides  mathematical 
operations  in  a  two-dimensional  data  structure.  Information  is  added  by 
users.  In  more  complex  applications,  the  tasks,  the  tools  and  the  information 
is  embedded  closely  so  that  the  software  application  is  used  as  a  whole. 

Workflow  is  a  new  term  in  the  computing  industry.  Workflow  diagrams  are 
used  to  represent  task  structures  explicitly,  with  each  task  in  the  workflow 
then  allocated  by  roles  in  the  organisation,  and  a  person  or  persons  allocated 
to  performing  the  role.  In  completing  the  tasks,  operators  may  require  one  or 
more  tools  along  with  sets  of  information  provided  from  various  databases. 

Increasingly  sophisticated  software  is  emerging  for  workflow  management. 
Such  software  is  capable  of  delivering  the  required  information  and  tools  to 
the  individual  users'  desktops  for  processing. 

Workflow  software  explicitly  represents  tasks,  tools,  information  and  roles. 
Each  of  the  components  are  defined  dynamically  so  that  users  can  change 
them.  It  is  even  possible  for  users  to  change  the  sequences  in  which  tasks  are 
performed,  in  response  to  changing  situations  and  personal  preferences. 

At  present  the  representation  of  tasks  in  workflow  diagrams  is  superficial. 
However,  such  diagrams  enable  enterprise-wide  operations  to  be  co¬ 
ordinated — ^providing  useful  support  for  standard  operating  procedures. 

The  use  of  workflow  diagrams  has  focused  functions  within  and  across 
organisations.  However,  the  concept  of  workflow  is  applicable  equally  to 
individuals  performing  cognitive  tasks.  For  example,  to  plan  air  tasking,  an 
OPSO  can  perform  several  cognitive  tasks — ^whether  the  tasks  are  performed 
depends  on  the  situation  at  hand  and  the  OPSO's  level  of  experience. 

•  The  User  Enterprise  Level  can  be  viewed  as  three  separate  levels  which  address 
the  needs  of  individuals,  groups  and  organisations. 

Historically,  computer  support  has  assisted  individuals  to  perform  relatively 
simple  tasks,  as  it  is  individuals  who  are  the  points-of-work  within  command 
and  control  systems  and  whose  needs  must  be  satisfied.  For  example, 
individuals  require  their  own  spaces  such  as  desktops  in  which  tasks  can  be 
performed  without  interruption  or  display  of  the  results  to  others.  The 
desktops  of  individuals  are  regarded  as  private  places  wherein  their 
customised  tools  are  available,  and  information  can  be  filed  via  individuals' 
own  systems. 

Desktops  are  the  points  at  which  individuals  fulfil  their  roles  within  the 
Command  Support  System.  If  the  concept  of  workflow  is  adopted,  then  the 
necessary  tools  and  iirformation  are  delivered  to  the  desktops  concerned  for 
individuals  to  fulfil  their  roles.  The  information  for  a  role  is  formatted  or 
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represented  by  what  is  called  a  view.  For  example,  air  tasking  information  can 
be  viewed  differently  according  to  whether  an  individual's  role  is  the  OPSO 
at  AHQ,  OPSO  at  wing  level  or  OPSO  at  squadron  level. 

Work  or  tasks  are  performed  by  agents  which  have  the  necessary  knowledge, 
information,  and  tools  to  manipulate  that  information,  and  the  information  in 
a  format  which  facilitates  the  use  of  the  tools  to  perform  the  task.  However, 
tools,  tasks,  information  and  representations  all  change  together  over  time. 
Users  will  also  need  a  means  to  transform  their  own  and  others'  tools, 
representations,  information  and  tasks. 

The  computer  industry  has  only  just  begun  to  recognise  the  paramount 
importance  of  providing  support  to  individuals  and  groups  of  workers. 
Software  tools  to  support  group  work  are  known  as  Groupware.  In  some 
respects,  ASMA  was  a  forerunner  of  today's  groupware  products,  as  it 
enabled  groups  of  people  to  communicate  and  collaborate  to  solve  problems. 
Important  information  was  entered  on  to  totes  so  that  it  could  be  shared  with 
other  headquarters  and  dialogues  developed. 

Groupware  technology  is  an  extension  of  electronic  mail  and  operates  from 
desktop-to-desktop.  Groups  of  people  are  able  to  see  the  documents 
generated  by  their  members — documents  may  be  in  any  media,  even 
multimedia. 

Groups  may  share,  or  be  separated  by,  time  and  space.  For  example,  in  the 
RAAF,  t5q>ical  roles  are  executed  by  people  who  are  part  of  functional  cells 
such  as  operations  or  plans.  To  fulfil  their  roles  in  such  fimctional  cells, 
individuals  often  require  a  common  understanding  of  the  situation  or 
problem,  or  must  be  kept  informed  as  information  is  received  by,  or 
generated  from  within,  fimctional  cells.  In  groups,  information  is  shared, 
tasks  allocated,  and  tools  are  necessary.  Workspaces  may  be  provided  for 
groups  where  all  information,  tasks  and  tools  are  represented  and  the  current 
states  of  the  situation  and  work  performed  are  displayed.  Workflows  within 
functional  cells  may  be  represented  explicitly  and  managed  in  the  cells' 
workspaces. 

Ensuring  a  common  understanding  across  several  headquarters  and 
functional  cells  is  essential  for  organisational  success.  For  example,  within 
HQ81  Wing  it  is  essential  that  everyone  is  kept  informed  of  current  situations 
in  terms  of  own  and  enemy  forces— in  particular,  81  Wing  assets.  This 
requires  that  common  information  and  tools  are  shared  across  organisational 
units. 


4.4.  Strategies  for  IS  Interoperation 

It  is  widely  accepted  that  information  technology  support  to  command  and  control 
requires  mechanisms  for  interoperability.  Such  interoperability  between  Command 
Support  Systems  in  the  ADF  and  between  our  allies  is  achieved  through  a  common 
message  format.  The  message  system,  ADFORMS  features  many  preformatted 
message  types  for  identified  situations.  ADFORMS  Interface  Machinery  is  soon  to 
provide  support  for  machine  formatting  of  ADFORM  messages.  Users  require  a  wide 
number  of  different  message  types  along  with  the  abilities  to  generate  and  refine 
messages,  if  interoperability  is  to  be  enhanced. 
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Interoperability  can  be  classified  into  three  levels: 

(i)  Connectivity  where  ISs  can  exchange  messages; 

(ii)  Interoperability  where  ISs  exchange  messages  to  request  and  receive  services 
from  each  other,  i.e.  they  use  other  users'  functionalities;  and 

(iii)  Co-operative  ISs  where  ISs  interoperate  to  execute  tasks  jointly. 

Achieving  co-operative  ISs  will  provide  users  with  a  Global  (Virtual)  Object  Space, 
which  contains  any  information,  tools,  and  tasks  required  by  users.  The  objects 
required  by  users  are  unlikely  to  be  stored  in  a  single  system,  however,  and  for  users 
to  retrieve  them  will  require  the  co-operation  of  agents  who  know  about  ISs,  to  process 
transactions. 

The  information  technology  community  is  aware  of  the  impossibility  of  integrating 
all  ISs.  Integration  would  imply  the  global  naming  of  data  items  along  with 
consistency  throughout  all  ISs — ^which  is  clearly  impossible.  Integration  occurs  at  the 
component  level  where  components  could  be  whole  ISs.  Component-oriented 
integration  is  useful  as  it  models  the  system  as  a  network  of  interacting  components,  it 
avoids  standardising  on  any  single  architectiure,  and  it  enables  components  to  be 
defined  independently  so  that  they  can  be  reused  in  different  architectural 
configurations  to  meet  requirements  as  they  evolve. 

4.4.1.  Architectural  Characteristics  Necessary  for  Interoperability 

To  achieve  interoperability,  developers  must  follow  an  object-oriented,  open, 
standards-based  approach  to  systems. 

An  object-oriented  paradigm  supports  the  use  of  messages  to  objects.  Message  can  be 
sent  to  objects  whose  abilities  to  receive  and  act  on  them  depends  only  on  the  interface 
of  the  componentry.  Locally-defined  procedures  for  objects  allow  components  to 
respond  independently  to  messages.  Procedures  may  be  changed,  independently  and 
transparently,  so  long  as  such  interfaces  are  maintained.  An  object-oriented  approach 
is  compatible  with  three  of  the  important  characteristics  required  of  interoperable  ISs: 
heterogeneity,  autonomy  and  distribution. 

Heterogeneity  means  that  not  all  systems  need  be  alike.  An  object-oriented  approach, 
in  fact,  supports  heterogeneity  by  focusing  on  the  sending  of  messages  to  component 
interfaces  rather  than  on  the  internal  architecture  of  systems. 

Object-orientation  also  supports  autonomy,  which  permits  all  systems  in  networks  to 
respond  in  their  own  ways,  by  allowing  procedures  to  be  defined  and  changed  locally. 

From  a  strategic  point-of-view,  distributed  systems  are  essential  in  terms  of  efficiency 
of  use,  reliability  and  survivability  of  computer  resources.  Object-oriented  techmques 
enable  multiple  processes  to  be  distributed  across  computer  networks. 

To  achieve  interoperable  ISs  requires  an  open,  standards-based,  approach  to  systems. 
Such  an  approach: 
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(i)  facilitates  extendability  and  system  evolution; 

(ii)  accommodates  heterogeneity,  autonomy  and  distribution; 

(iii)  avoids  duplication  of  effort  by  combining  technologies  developed  by 
industry  consortia  and  standards  bodies;  and 

(iv)  encourages  reuse  of  resources. 

To  enable  organisations  to  focus  their  efforts  towards  tailoring  their  software  towards 
their  unique  requirements,  IS  implementation  has  tended  to  standardise  aspects  which 
are  common  across  applications,  and  in  a  vendor-independent  manner.  Services 
corrunon  to  applications  and  located  between  the  applications  and  the  operating 
systems  are  known  as  middleware.  The  aim  of  middleware  is  to  provide  a  high-level, 
platform-independent  environment  for  the  development,  maintenance,  and  run-time 
support  of  distributed  applications  (see  Figure  7). 

Middleware  provides  many  of  the  building  blocks  for  the  development  of 
heterogeneous,  autonomous,  and  distributed  systems.  Among  the  distributed 
computing  services  provided  by  middleware  are  user  interface  components, 
distributed  computing  environments,  software  development  environments  for 
computer-aided  software  engineering,  and  modelling  tools,  along  with  tools  for  data 
management  and  access,  asset  management,  computer  network  management, 
telecommunications  network  management,  and  security. 

Development  of  applications  on  top  of  middleware  services  requires  an  architectiu-e 
which  allows  distributed  applications  to  be  integrated.  This  is  the  aim  of  the  Common 
Object  Request  Broker  Architecture  (CORBA)  put  together  by  the  Object  Management 
Group.  Applications  specific  to  particular  organisations  such  as  RAAF  Command  and 
Control  are  able  to  call  on  information  and  tools  from  global  object  spaces,  including 
military-specific  object  spaces  for  security  reasons,  and  can  use  services  provided  by 
CORBA  which  enable  distributed  object  management. 


ORGANISATION  SPECIFIC 
APPLICATIONS 


Figure  7.  Application  construction  and  maintenance  services  for  interoperable  ISs  (OS  = 
operating  system,  CORBA  =  Common  Object  Request  Broker  Architecture). 
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Middleware  and  distributed  object  management  systems  permit  end  users  to  develop 
applications  to  support  their  core  businesses  without  having  to  know  the 
implementation  details  or  origins  of  the  objects  used.  Object-based  development  of 
applications  is  shown  in  Figure  8.  Support  for  the  core  business  of  RAAF  Command 
and  Control  such  as  applications  for  operations,  planning,  intelligence,  administration 
and  management  are  developed  using  an  object  management  system.  Each  business 
application  is  then  specialised  for  activity  segments  such  as  air  defence,  surveillance, 
maritime  interdiction — ^with  local  specialisations  for  organisational  units. 
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Figure  8.  Open  systems  architecture  for  development  of  object-based  applications. 

Object-based  applications  development  is  ongoing  in  general  software  engineering 
environments  where  fundamental  applications  are  developed  and  databases 
implemented — specific  software  engineering  environments  may  also  act  as  venues. 
These  enable  end-users  to  access  and  define  objects  which  produce  tools,  views  and 
applications  for  use  by  themselves,  by  other  operators,  and  by  groups. 

4.4.2.  Interoperability  Requirements 

ACSS  users  will  source  much  of  the  information  they  require  not  from  the  ACSS  itself 
but  via  electronic  links  to  other  RAAF,  ADF  and  even  commercial  systems.  The  links 
most  likely  required  are  listed  in  Table  1.  Electronic  links  to  other  systems  may  be 
established  also  on  an  as-required  basis  provided  security  restrictions  remain 
unviolated.  In  this  case,  the  electronic  links  are  not  necessarily  physical  point-to-point 
connections — for  example,  the  use  of  Defence  Switched  Data  Network  will  provide 
greater  flexibility  in  communication.  The  inter-networking  of  future  systems  will 
enable  system  managers  to  establish  and  manage  networks  which  are  logical  rather 
than  physical — establishing  virtual  private  networks. 
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Table  1. 


Organisation,  system  and  possible  information  interoperability  requirements 


Organisation 

System 

Possible  Information 

HQADF 

JCSE 

From;  Policy  and  request  for  information 

To:  Status,  responses  and  requests  for  policy 

MHQ& 

Fleet 

JOTS  or  MIST 

OBU 

From:  Status  (data,  text,  graphics),  requests  and  responses 

To:  Status  (data,  text,  graphics),  requests  and  res^nses 

LHQ& 

Units 

AUSTACCS 

LCOCSS 

From;  Status  (data,  text,  graphics),  requests  and  responses 

To:  Status  (data,  text,  graphics),  requests  and  responses 

HQJFA 

CCIS 

From:  Policy  and  request  for  information 

To:  Status,  responses  and  requests  for  policy 

RAAF 

AHQLAN 

BACSS 

NADACS  -  Air 
defence,  air  control 
command  and  control 
system,  JORN, 
CAMM2 

Logistic  support 
systems 

From:  Sensor,  operational,  maintenance  and  logistic 
information 

To:  Requests,  responses 

ADF 

Topographic  support 
system 

Form:  Natural  and  artificial  features  of  specified  area 

To:  Requests  for  area  topography 

DIO 

ADFDIS 

From:  Strategic  intelligence,  and  current  intelligence  as 
available 

To:  Situation  reports,  requests  for  information 

Allies 

From:  Status  (data,  text  and  graphics)  requests  and 
responses 

To:  Status  (data,  text  and  graphics)  requests  and  responses 

Coastwatch 

From:  Ship,  aircraft  information,  requests  for  assistance, 
sensor  taskings 

To:  Requests  for  information,  results  of  sensor  tasking 

Customs 

From:  Situation  information  and  requests  for  assistance 

To:  Requests  for  information 

raBH 

From;  Situation  reports,  SAR  and  medevac  requests 

To:  Requests  for  information 

Bureau  of 
Meteorology 

From:  Current  and  forecast  weather  for  specified  location 
To:  Requests 

4.5.  Performance 

4.5.1.  CSS  Performance  Issues 

The  performance  of  a  CSS  is  dependent  on  the  complexity  of  the  task  performed,  the 
amount  of  information  and  knowledge  required,  and  the  experience  and  expertise  of 
the  users.  It  is  difficult  to  predict  the  tasks  performed  and  users'  abilities  at  any  instant 
in  time.  Worst-and-best-case  scenarios  may  be  used  to  help  predict  possible  usages. 


4.5.2.  IS  Performance  Issues 

The  performance  of  distributed  systems  depends  largely  on  the  effective  allocation  and 
management  of  resources.  Where  possible,  large  volumes  of  information  should  be 
processed  locally,  if  communication  lines  are  to  be  used  efficiently.  Distributed 
database  transactions  for  text,  graphics,  images,  geographic  and  video  information  can 


be  bandwidth-intensive.  Where  possible,  the  information  transmitted  should  be 
change  information  only,  and  the  use  of  locally-available  tools  should  be  maximised. 

If  ACSS  becomes  a  fully  interoperable  IS,  its  response  times  will  depend  partially  on 
the  systems  with  which  it  interacts — such  response  times  should  be  acceptable  to  the 
ACSS. 

The  storage  media  for  electronic  information  has  become  more  powerful  and 
cheaper.  At  the  same  time,  the  type  of  information  that  can  be  stored  in  electronic 
media  has  become  more  diverse,  and  of  vast  capacities.  ACSS  will  be  required  to  store 
video,  image,  graphics,  and  sound,  along  with  text. 

4.6.  Security 

4.6.1.  CSS  Security  Issues 

CSS  security  needs  to  provide  privacy  and  trust  to  all  aspects  of  user  organisations. 
Security  ensures  that  information  limited  by  any  need  to  know  basis  is  accessed  only  by 
those  with  the  right  to  do  so.  The  use  of  roles  in  defining  information  requirements 
limits  those  who  can  access  certain  information  and  tools  in  their  object  spaces,  on 
other's  desktops,  and  through  their  workspaces  and  blackboards.  The  use  of  views 
restricts  how  information  is  represented,  while  tools  limit  the  ways  in  which  users  can 
manipulate  the  information. 

Request  to  alter  access  to  information  can  be  made  only  by  requesting  the  authority 
from  the  author  or  from  specified  authorities. 

4.6.2.  IS  Security  Issues 

Ultimately  ACSS  should  be  able  to  handle  all  information  ranging  from  unclassified  to 
Top  Secret  codeword.  Staff  may  be  required  to  work  with  mixed  security  systems  as  an 
interim  arrangement  until  multi-level  secure  systems  become  available. 

Most  of  the  information  handled  by  ACSS  is  classified  at  Secret  or  below.  Special 
intelligence  information  may  be  separated  from  general  service  information  by  the  use 
of  trusted  one-way  gateways. 

ACSS  may  require  networks  operating  at  TS  codeword,  Secret  (AUSTEO)  system  high, 
and  Restricted.  It  may  also  require  access  to  systems  operating  at  various  security 
levels. 

Current  initiatives  in  the  development  of  secure  multi-level  environments  rest  with 
compartmented  mode  workstations  and  trusted  gateways  linking  system  high 
networks.  Compartmented  mode  workstations  require  accreditation  and  will  always 
be  one  to  two  years  behind  the  state-of-the-art  as  the  accreditation  process  freezes  the 
technologies. 

Trusted  gateways,  such  as  the  DSTO-developed  STUBS,  can  be  fitted  retrospectively 
to  systems  and  offer  greater  flexibility  than  the  use  of  compartmented  mode 
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workstations.  ACSS  should  also  address  its  requirements  for  secure  database  facilities 
as  these  appear  to  have  matured  to  the  B1  level. 

Traditionally,  trusted  systems  have  addressed  operating  systems  and  network 
aspects  of  their  usage.  Secure  databases  are  a  move  to  providing  security  features  in 
other  computer  software.  Security  features  may  well  be  developed  for  other 
applications  such  as  sharing  tools,  document  preparation  tools,  and  so  on.  ACSS 
should  assure  data  integrity  in  terms  of  validated  authorities  for  data  held  by  the 
system,  which  should  be  developed  in  accordance  with  SECMAN3.  As  well,  an 
automatic  log  of  systems  usage  should  be  kept  for  security  purposes  which  notes  staff 
log-on  and  log-off  times. 


4.7.  IS  Availability,  Reliability  and  Maintainability 

A  system  failure  in  the  middle  of  a  key  RAAF  operation  could  have  severe 
consequences.  Therefore  an  operational  system  needs  to  be  highly  available  and 
reliable.  Availability,  determined  by  users'  access  to  systems,  is  dependent  upon  the 
number  and  location  of  workstations  and  on  the  systems'  reliability,  namely,  its 
capacity  to  operate  without  significant  downtime  during  anticipated  operations. 
Maintainability  is  the  system  administrator's  ability  to  perform  routine  maintenance,  to 
make  minor  changes  to  the  system,  and  conduct  general  house-keeping  operations 
without  interrupting  the  users  during  operations. 

The  ACSS  should  be  designed  which  is  highly  available  and  reliable,  which  reqtxires 
replication  and  distribution  of  data  services,  and  the  adoption  of  routine  maintenance 
procedures  which,  when  carried  out,  cause  as  little  disruption  as  possible  to  other 
users. 


4.8.  Usability 

A  Command  Support  System  must  be  usable,  in  that  many  key  military  decisions  are 
made  under  stressful  conditions.  It  is  essential,  therefore,  that  the 
Coiiunand  Support  System  assists  rather  than  hinders  decision-makers  by  removing, 
rather  than  by  placing,  obstacles  in  the  path  of  users.  Difficult  tasks  performed  often  by 
users  of  Command  Support  Systems  demand  that  the  system  and  its  results,  namely, 
its  decisions,  are  usable. 

4.8.1.  CSS  Usability  Issues 

The  general  framework  of  usability  embraces  four  principal  components  of  any  work 
situation — user,  task,  system  and  environment.  Effective  usability  depends  upon 
achieving  a  dynamic  harmony  between  these  four  components. 

A  universal  in  the  development  of  information  systems  is  that  such  systems  should 
be  designed  for  the  people  who  are  to  use  them.  The  release  of  hvunan  productivity 
and  creativity  demands  that  products  and  systems  are  tailored  to  the  physical  and 
mental  characteristics  of  their  users.  Environments  and  systems  well  tailored  to  the 
needs  of  users  will  be  more  usable  than  those  which  are  not. 
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As  a  concept,  usability  is  not  easy  to  define.  All  too  often  requirements  specifications 
use  terms  such  as  user  friendly  which  can  not  be  measured  objectively.  Usability  may  be 
specified  and  measured  in  terms  of  operational  criteria  such  as  effectiveness, 
leamability  and  attitudes.  Effectiveness  states  the  level  of  performance  achieved  when 
performing  particular  tasks.  Leamability  is  the  ease  of  learning  or  re-leaming  tasks,  and 
attitude  is  the  level  of  satisfaction  which  operators  gain  from  using  the  system. 

Specifying  usability  criteria  for  tasks  performed  by  ACSS  would  require  enormous 
effort — such  an  approach  assumes  that  systems,  once  built,  are  not  changed.  Good 
usability  derives  from  tailoring  software  to  meet  the  physical  and  mental 
characteristics  of  its  users.  Tailoring  in  this  instance  should  be  interpreted  as  tailoring 
by  users  to  meet  their  own  physical  and  mental  preferences  in  particular  situations. 

Tailoring  is  regarded  widely  as  the  setting  of  one  or  two  parameters  within 
applications.  Usability  of  futiue  systems  also  should  address  radical  tailoring,  that  is, 
providing  radically  tailorable  environments  which  allow  users  to  develop  their  own 
representations  of  information,  tasks  and  tools.  Organisations  may  have  set  guidelines, 
as  in  paper-based  systems,  but  users  should  not  allow  themselves  to  be  constrained  too 
much  by  them. 

4.8.2.  IS  Usability  Issues 

ACSS  should  adopt  a  clear  and  consistent  user-interface  that  requires  a  minimum  of 
training  and  provides  an  environment  in  which  the  users  can  tailor  tools,  information 
and  views  to  their  own  requirements. 

4.9.  Flexibility 

That  command  and  control  needs  to  be  flexible  and  adapting  has  been  stressed  many 
times  in  this  paper.  Command  and  control  is  very  much  about  making  rapid 
organisational  changes  to  meet  emerging  threats.  ACSS  should  be  designed  to  at  least 
mirror,  if  not  extend,  the  flexibilities  of  manual  systems  where  roles,  responsibilities 
and  information  requirements  are  modified  to  meet  the  demands  of  rapidly  changing 
situations. 

4.9.1.  CSS  Issues 

CSS  software  should  permit  the  d5mamic  allocation  of  roles,  tools,  information  and 
views,  providing  users  with  the  flexibility  to  create  and  change  organisational  units 
along  with  their  associated  roles,  tasks,  workflows,  views  and  information. 

Users  may  need  also  to  make  changes  to  their  information  access  rights,  along  with 
their  abilities  to  request  information  from  other  users  who  may  form  part  of  the  ACSS, 
especially  in  the  face  of  unpredicted  and  rapidly-escalating  threats. 

4.9.2.  IS  Issues 

Hardware  flexibility  should  permit  the  dynamic  reconfiguration  of  networks  where 
necessary.  For  instance,  the  wider  use  of  wireless  technologies  and  intelligent 
networks  should  be  investigated. 
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IS  software  flexibility  is  achievable  through  the  adoption,  wherever  possible,  of  open 
systems  standards. 

4.10.  Survivability 

Command  and  control  is  pivotal  to  effective  military  operations,  and  the  importance  of 
command  and  control  centres  of  operation  make  them  worthy  targets  for  enemies.  If 
computer  networks  or  communication  links  are  damaged  by  hostile  activities,  it  is 
imperative  that  their  performance  degrades  gracefully,  and  that  alternative  services 
can  be  made  available. 


4.10.1.  CSS  Survivability  Issues 

CSS  survivability  can  be  achieved  through  the  dynamic  ability  to  reconfigure  tools, 
tasks,  information  and  views  delivered  to  nodes  in  the  command  chain. 

4.10.2.  IS  Survivability  Issues 

Survivability  and  the  ability  to  sustain  operations  in  the  face  of  hostile  activities  may 
be  achieved  by  the  use  of  replicated  and  distributed  IS  architectures.  Such  architectures 
provide  greater  robustness  which  reduces  the  chance  of  catastrophic  failiue.  However, 
the  trade-off,  namely  the  task  of  managing  the  more  complex  system  itself,  becomes 
more  complex— a  task  that  is  starting  to  be  addressed  by  the  appropriate  software 
tools. 

4.11.  Communications 

Modern  air  warfare  is  characterised  by  the  use  of  deception  tactics,  a  high  element  of 
surprise,  and  rapid  event  times.  All  these  factors  combine  to  reduce  the  time  available 
for  considered  decision-making.  To  alleviate  the  problem,  the  RAAF  Command  and 
Control  system  must  be  designed  to  provide  real-time,  secure  communications  which 
are  highly  available. 

4.11.1.  CSS  Communications 

CSS  commurucations  also  address  the  standard  procedures,  protocols,  and  personal 
etiquette  of  communications  between  people  inhabiting  distributed  locations,  while 
commanders  gain  a  high  level  of  understanding  of  situations,  problems,  options, 
solutions  and  different  methods  for  executing  said  solutions.  Information  may  be 
communicated  in  the  forms  of  text,  graphics,  sound  and  video — all  these  media  may 
also  communicate  their  information  interactively  or  non-interactively. 

4.11.2.  IS  Communications 

The  current  Defence  strategic  communications  network  provides  a  range  of  secure, 
non-secure  and  survivable  communication  services.  However,  many  of  the  services  are 
provided  by  proprietary  software  packages,  and  use  hardware  which  is  inflexible, 
technically  out-of-date,  expensive  to  maintain  and  operate,  and  which  constitutes  an 
inefficient  use  of  natural  resources. 
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Studies  have  determined  that  Defence  Fixed  Networks  can  migrate  to  systems  having 
standard,  open,  non-proprietary  interfaces  and  protocols  where  possible.  It  is  hoped 
that  through  the  adoption  of  international  standards  for  military  communications, 
computing  resources  can  be  distributed  more  effectively  and  communications 
capacities  allocated  more  dynamically  among  command  centres. 

To  ensure  that  international  civilian  standards  meet  the  special  needs  of  military 
users,  the  NATO  Tri-Service  Group  on  Communications  and  Electronics  SubGroup 
Nine  defined  eight  features  considered  essential  when  using  such  systems  in  military 
operations.  If  civilian  standards  are  deemed  not  to  meet  those  set  by  military  users, 
NATO  will  attempt  to  influence  the  ISO  and  ITU  standards  formulation  to  incorporate 
military  requirements  into  civilian  standards — ^military-specific  standards  will  be 
developed  only  as  a  last  resort.  Australia  is  likely  to  adopt  a  similar  approach. 

A  key  consideration  for  ACSS  is  not  so  much  the  adoption  of  standards,  but  the 
difficulties  faced  in  developing  systems  which  can  migrate  as  communications  systems 
in  step-wise  increases  in  capacity  and  performance.  The  development  of  ACSS  may  be 
driven  by  the  need  to  make  best  use  of  the  evolving  global  communications 
infrastructure. 


5.  Support 


5.1.  Training 

Modem  computer  software  is  often  complex  and  changes  rapidly,  so  that  its  mastery 
requires  a  high  level  of  computer  literacy  and  on-going  training.  Doubtless,  future 
users  of  ACSS  will  be  familiar  and  comfortable  with  operating  computer  systems. 
However,  training  will  be  needed  for  COTS  and  other  special  software  products.  A 
training  program  will  be  needed  to  achieve  and  maintain  required  skill  levels.  Support 
facilities  for  training  will  also  be  needed. 

Training  in  the  use  of  software  is  very  different  to  training  individuals  and  teams  for 
command  and  control  decision-making.  The  training  facilities  required  for  command 
and  control  exercises  need  also  to  be  provided.  Use  of  flexible  scenario-generation 
tools  which  can  combine  live  and  simulated  data  can  be  used  to  support  an  advanced 
and  highly  realistic  training  programme. 

5.2.  Life  Cycle  Support 

It  is  to  be  agreed  by  what  means  the  ACSS  will  be  procured.  The  present  intention  is 
for  an  Evolutionary  Acquisition  which  establishes  an  overall  framework,  implements  a 
core  system,  and  defines  any  subsequent  increments  according  to  emerging  needs. 

Should  an  evolutionary  rather  than  whole-procurement  approach  be  adopted  for  the 
ACSS,  several  system  environments  may  need  to  be  established: 

(i)  A  development  environment  for  new  software,  for  testing  new  ideas,  and  for 
investigating  initial  integration  issues; 
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(ii)  A  testing  environment  for  the  detailed  testir\g  of  new  facilities,  and  for 
conducting  system  upgrades  before  going  live;  and 

(iii)  A  live  environment  for  24-hour  operations  by  RAAF  personnel. 

Whether  these  environments  need  to  be  separate,  systems  should  also  be 
investigated.  The  relationship  between  the  training  facilities,  the  testing  and  the  live 
environments  may  also  require  special  study. 

The  need  to  integrate  the  working  relationship  of  procurers,  industry  personnel, 
users,  and  researchers  much  more  closely  has  been  highlighted  as  a  potential  avenue 
for  radical  reductions  in  the  time  between  identification  of  problems  and 
implementation  of  solutions.  Even  with  evolutionary  acquisition,  new  problems  which 
arise  will  require  innovative  solutions  from  researchers.  Tools  for  diagnosing  and 
analysing  problems  should  be  available  in  the  development  of  test  and  live 
environments. 

Requirements  is  not  a  one-off  assessment.  New  and  unforeseen  requirements  will  arise 
with  more  advanced  software  technologies.  Often  it  is  the  computer's  ability  to  meet 
the  basic  requirements,  along  with  the  users'  changing  perceptions  or  mental  models 
of  the  requirements  which  are  themselves  changing.  ACSS  should  provide,  trial,  and 
implement  tools  which  express  the  new  requirements  and  offer  the  development  and 
trialing  of  possible  solutions. 

This  paper  has  suggested  that  open,  standards-based,  information  systems  should  be 
adopted  which  are  interoperable,  and  which  offer  distributed  object  management  and 
an  effective  representation  of  the  work  performed  within  the  command  and  control 
domain.  This  will  lead  to  a  system  that  is  user-dependent  rather  than  procurement- 
dependent.  Although  the  procurement  process  will  be  responsible  for  putting  the  basic 
building  blocks  in  place,  eventually  it  will  be  the  users  who  will  decide  how  the 
system  operates  best  for  them. 


6.  Summary  of  Broad  Capabilities 

1.  RAAF  CSS  should  be  implemented  in  an  environment  which  has  clearly 
identified  the  business  functions  it  supports. 

2.  RAAF  CSS  should  support  individual  commanders  in  executing  their  duties. 
This  will  require  the  ability  to  tailor  information,  tools,  tasks  and  views  to 
meet  their  individual  needs  and  the  requirements  of  rapidly-evolving 
situations. 

3.  RAAF  CSS  should  represent  the  organisation  and  its  purpose. 

4.  RAAF  CSS  should  represent  the  functional  areas  within  the  organisation  and 
the  work  carried  out  by  those  areas. 

5.  RAAF  CSS  should  represent  the  organisational  units  within  the 
organisational  framework  and  the  work  performed  by  them. 

6.  RAAF  CSS  should  represent  the  roles  performed  within  organisational  units. 


32 


7.  RAAF  CSS  should  provides  a  navigation  tool  to  enable  users  to  navigate 
through  the  system  with  its  multiple  perspectives — in  terms  of  its  roles,  tools, 
information,  organisational  units,  personnel,  tasks,  and  combinations  of 
these. 

8.  RAAF  CSS  should  support  co-ordination  of  work  through  sharing  tools  and 
workflow  models. 

9.  RAAF  CSS  should  support  the  workings  of  individuals,  groups,  and  the 
organisation. 

10.  RAAF  CSS  should  support  distributed  decision-making. 

11.  RAAF  CSS  should  support  enhanced  situation  awareness. 

12.  RAAF  CSS  should  support  situation  assessment  and  plaiming. 

13.  RAAF  CSS  should  support  training. 

14.  RAAF  CSS  should  perform  to  the  requirements  of  the  tasks  performed  by 
users. 

15.  RAAF  CSS  should  provide  private  areas  in  which  individuals  can  tailor  their 
tools,  tasks,  information,  views  and  methods  of  information  management  to 
their  own  requirements. 

16.  RAAF  CSS  should  support  several  levels  of  fusion. 

17.  RAAF  CSS  should  enable  users  to  alter  the  characteristics  of  tools, 
information,  views  and  roles  in  order  to  meet  their  usability  requirements. 

18.  RAAF  CSS  should  provide  flexible  environments  in  which  the  organisational 
structures  can  be  changed,  and  roles,  tools,  tasks,  views  and  information  re¬ 
allocated. 

19.  RAAF  IS  should  be  implemented  so  that  their  functions  are  transparent  to 
users. 

20.  RAAF  IS  should  adopt  an  object-oriented,  open,  standards-based  approach  to 
information  systems. 

21.  RAAF  IS  should  interoperate  with  other  ADF,  Goverrunent  and  civil  IS. 

22.  RAAF  IS  should  adopt  middleware. 

23.  RAAF  IS  should  support  distributed  object  management. 

24.  RAAF  IS  should  process  IS  messages  in  a  timely  manner. 

25.  RAAF  IS  should  provide  multi-level  security  to  all  information,  tasks,  tools 
and  views  regardless  of  their  media. 
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7.  Conclusions 


1.  This  document  has  defined  the  broad  capabilities  required  of  future  RAAF 
Command  Support  Systems.  It  recognises  that  broad  capabilities  can  be 
specified  but  user  requirements  are  subject  to  changes  and  that  environments 
are  needed  to  support  such  changes. 

2.  The  time-line  associated  with  developing  an  ACSS  is  unclear  so  that  our 
approach  has  been  to  define  broad  capabilities  for  a  CSS  that  are  not 
implementation-specific  and  have  some  longevity. 

3.  A  framework  has  been  developed  which  highlights  the  need  for  four  kinds  of 
fusion  within  a  CSS:  fusions  of  sensor,  data,  information  and  knowledge. 

4.  The  RAAF  currently  has  a  niimber  of  disparate  systems  which  are  poorly 
connected  and  which  do  not  interoperate.  An  understanding  of  the  IS 
environment  required  to  support  the  broad  capabilities  of  a  RAAF  CSS, 
however,  is  beginning  to  emerge.  Adopting  an  open,  standards-based 
approach  to  systems  will  provide  the  RAAF  with  the  necessary  flexibility  to 
achieve  IS  interoperability. 

5.  Current  RAAF  systems  support  mainly  sensor  and  data  fusion.  Few 
initiatives  have  been  made  in  support  of  information  and  knowledge  fusion. 
Unless  knowledge  fusion  is  achieved,  a  RAAF  CSS  will  not  be  able  to  support 
its  role  at  a  future  joint  headquarters. 

6.  A  distinction  has  been  made  between  IS  and  CSS  capabilities,  which  helps  to 
separate  general  IS  issues  from  specific  CSS  issues,  and  in  doing  so  clearly 
establishes  the  difference  between  CSSs  and  other  types  of  support  systems. 

7.  RAAF  CSS  should  provide  support  to  individual  commanders  in  situations 
difficult  to  predict.  Such  tailorable  environments  will  permit  maximum 
usability  in  the  field. 

8.  Central  to  the  operation  of  a  RAAF  CSS  are  intelligent  agents  or  people  who 
perform  roles  in  organisations.  To  carry  out  their  assigned  roles  and  tasks, 
intelligent  agents  require  information,  tools  to  manipulate  information, 
knowledge  of  the  tasks  to  be  performed  by  individuals  and  teams,  and  all  of 
the  information  presented  for  maximum  comprehension. 

9.  The  tasks,  tools,  information  and  views  required  by  individuals  will  change 
as  operating  enviromnents  change.  Also  required,  therefore,  is  the  ability  to 
change  all  domain  aspects  of  the  system. 

10.  RAAF  CSS  development  should  concentrate  on  supporting  the  business 
aspects  specific  to  RAAF  Command  and  Control.  Generic  aspects  of 
applications  can  be  provided  by  COTS  products  and  services. 

1 1 .  RAAF  CSS  should  achieve  a  necessary  balance  between  struchured 
environments  and  those  that  provide  flexibility,  which  support  information- 
push  as  well  as  user-pull,  and  in  which  users'  questions  are  processed 
transparently — ^with  smart  navigation  tools  supplied. 

12.  Rapid  distributed  decision-making  is  essential  for  air  operations.  RAAF  CSS 
should  provide  tools  for  communicating  and  sharing  complex  information 
and  knowledge. 
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13.  RAAF  CSS  information  flows  may  be  formal  or  informal.  Formal  information 
flows  may  be  supported  by  workflow  models.  Informal  information  flows  are 
situation-dependent  and  are  more  difficult  to  pre-specify — it  is  important, 
therefore,  that  a  CSS  supports  both  formal  and  informal  communications  of 
information. 

14.  A  RAAF  CSS  needs  to  support  users  in  their  situation  awareness,  situation 
assessment  and  planning.  This  requires  sophisticated  tools  to  be  developed 
which  are  compatible  with,  and  which  meet,  the  changing  demands  of 
individuals  and  situations. 

15.  Development  of  RAAF  CSS  should  proceed  within  sound  technical 
frameworks  compatible  with  the  acquisition  strategy  planned.  Should  an 
evolutionary  acquisition  approach  be  adopted,  several  systems  may  be 
required  for  prototyping,  testing,  training  and  live-running. 

16.  RAAF  CSS  development  accepts  the  capabilities  which  are  currently 
operational.  Strategies  for  migrating  from  current  legacy  systems  to  open 
systems,  and  for  enhancing  CSS  functionality  in  doing  so,  need  to  be 
identified. 

17.  Computer  hardware  and  communications  are  falling  rapidly  in  price  and 
becoming  increasingly  more  powerful  and  capable.  The  challenge  now  is  to 
produce  more  sophisticated  and  sympathetic  support  to  users.  If  IS  is  the 
domain  of  information  specialists  and  procurers,  CSS  should  be  the  domain 
of  its  operators  and  users. 

18.  Security  poses  a  major  challenge  for  flexible  CSS  and  IS  development.  For  this 
reason,  computer  security,  information  security  and  CSS  security  are  unlikely 
to  be  automated  fully  in  the  near  future. 
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